哈囉大家好，歡迎來到 CI/CD 自動化生產線的最後一哩路！

在過去幾天，我們的 Pipeline 已經能夠自動化地完成測試 (test) 與建置映像檔 (build) 的任務。我們的 Harbor 倉庫中，現在已經存放著帶有每一個 commit-hash 標籤的、熱騰騰的 Docker Images。

但這只完成了 CI 的部分。今天，我們的目標是打通 CD (Continuous Deployment) 的任督二脈，讓我們的生產線實現真正的端到端自動化：從 git push 開始，到應用程式在 Kubernetes 叢集中被自動更新為最新版本結束。

Part 1：deploy 任務的核心三問

要讓 GitLab Runner 自動地幫我們部署應用到 K8s，它必須先回答三個核心問題。我們的 .gitlab-ci.yml 中 deploy 階段的設定，正是為了回答這三個問題。

問題一：Runner 如何取得 K8s 的操作權限？

答案：透過 kubeconfig 檔案。

kubeconfig 就像是進入我們 K8s 叢集的「數位鑰匙」。我們不可能把這把敏感的鑰匙明文寫在 .gitlab-ci.yml 裡。

正確的做法是：

1. 我們將 kubeconfig 檔案的內容，預先儲存在 GitLab 專案的一個受保護的 CI/CD 變數中（例如，取名為 KUBE_CONFIG_DEV）。
2. 在 deploy 任務開始時，我們會有一段 before_script，它的作用就是在 Job Pod 內部，動態地將這個變數還原成一個真實的 ~/.kube/config 檔案。

透過這種方式，我們就安全地將操作 K8s 叢集的權限，臨時授予了這個 deploy Job。

問題二：Runner 要執行什麼部署動作？

答案：執行 helm upgrade --install 指令。

一旦 Runner 擁有了權限，它就可以像我們在本機一樣，執行 kubectl 或 helm 指令。在我們的專案中，我們使用 Helm 來管理應用程式。

helm upgrade --install 是一個非常實用的組合指令，它的意思是：

「請嘗試升級 (upgrade) 一個名叫 ota-service-dev 的應用。如果它還不存在，就幫我安裝 (install) 一個新的。」

這讓我們的 Pipeline 可以處理「首次部署」和「後續更新」這兩種情境。

問題三：Runner 如何知道要部署哪個版本？

答案：透過 --set 旗標，動態傳入 Image Tag。

這是連接 CI 與 CD 最關鍵的一環！我們在 build 階段，建置出來的 Image 都有一個獨一無二的標籤（例如 a1b2c3d4，來自 commit hash）。我們必須告訴 Helm，這次部署要用的就是這個新的 Image。

這可以透過 helm 指令的 --set 旗標來完成：

`helm upgrade ... --set backend.image.tag=${CI_COMMIT_SHORT_SHA}`

這行指令會在執行時，動態地覆寫 Helm Chart 中的預設值，確保 K8s 會去拉取我們剛剛才建置出來的、最新的 Image 來進行部署。

Part 2：簡化版的 deploy Job 範例

了解了背後的原理後，讓我們來看一個簡化版的 deploy:dev Job，它清晰地體現了上述三個核心概念：

# .gitlab-ci.yml (deploy:dev 簡化版)

deploy:dev:
  stage: deploy:dev
  image: alpine/k8s:1.28.3 # 一個內建 kubectl/helm 的好用 Image
  tags:
    - docker
  
  before_script:
    # 步驟一：取得 K8s 操作權限
    - echo "正在從 CI/CD 變數載入 kubeconfig..."
    - echo "${KUBE_CONFIG_DEV}" | base64 -d > ~/.kube/config
    - apk add --no-cache helm
    
  script:
    # 步驟二 & 三：執行部署，並傳入最新 Image Tag
    - echo "開始使用 Helm 部署版本 ${CI_COMMIT_SHORT_SHA}..."
    - helm upgrade --install ota-service-dev ./helm/ota-service \
      --namespace project-space \
      -f ./helm/ota-service/values-dev.yaml \
      --set backend.image.tag=${CI_COMMIT_SHORT_SHA} \
      --set frontend.image.tag=${CI_COMMIT_SHORT_SHA}
      
  # needs 關鍵字確保此任務在 build 成功後才執行
  needs:
    - build:backend
    - build:frontend

Part 3：一條完整的自動化生產線！

現在我們終於可以將整條生產線的流程圖完整描繪出來。

結論

今天，我們打通了 CI/CD 的最後一哩路，掌握了自動化部署的三個核心步驟：授權 (kubeconfig)、執行 (helm upgrade)、以及傳遞版本 (--set)。

但當叢集中的微服務越來越多，它們之間的網路流量會變得錯綜複雜。我們該如何有效地管理、監控、並保護這些服務之間的通訊呢？

在下一階段，我們將認識 Istio 服務網格！明天見！